一台應用伺服器的資源就三樣：CPU、內存（Memory）、I/O。它們互相競爭，一個見頂，全站跟著陪葬。本節就解剖這三種瓶頸。書本用網站的實物介紹電腦三個資料系統，或說計算機架構，的互動和需求，讀了讓我更有想法，和好觀點去讀 CSAPP 這種書，後者相對太各章集中了，有點失去應用。

在網路容器服務中，這三種資源會直接影響使用者的等待時間。CPU 不足時，容器處理請求的速度變慢，連線數一多就會出現逾時。Memory 不足時，系統可能開始使用 Swap，甚至觸發 OOM Killer，直接停止某個容器。I/O 過慢時，資料庫、日誌和檔案讀寫會互相等待，表面上看起來像程式變慢，實際上卻是磁碟或網路儲存成為瓶頸。

今天先為每個容器設定資源上限，避免單一服務吃光整台伺服器。例如使用 Docker Compose 時，可以為服務加入 CPU 和記憶體限制：

services:
  app:
    image: my-app:latest
    deploy:
      resources:
        limits:
          cpus: "1.0"
          memory: 512M

設定限制之後，還要觀察實際使用量。可以先使用 docker stats 查看容器的 CPU、記憶體、網路和區塊 I/O。測試時不要只開一個請求，而是逐步增加連線數，記錄平均延遲、最高延遲、錯誤率和每秒處理量。只有這樣，才能知道瓶頸究竟出現在應用程式、資料庫，還是主機本身。

具體的處理順序是先確認 CPU 使用率，再檢查記憶體是否持續增加，最後觀察 I/O 等待。如果 CPU 長時間接近滿載，就先減少不必要的計算，或增加執行個體數量。如果記憶體持續上升，就檢查是否有快取沒有釋放，並設定容器重啟和監控警示。如果 I/O 過高，就降低過度日誌，將資料庫和應用程式分開，必要時改用快取或非同步寫入。

這次最大的收穫，是不要只看程式碼本身。網路服務是一個完整系統，容器、作業系統、資料庫、磁碟和網路都會互相影響。先量測，再限制，再調整，最後才考慮擴充硬體，才能用最少成本找到真正的問題。